如spark://host1:port1，这时， 注意：不能将Master定义在conf/spark-env.sh里了。

加入ZooKeeper的集群整体架构如下图所示， 1.基于文件系统的单点恢复 主要用于开发或测试环境，Spark提供了两种方案： 基于文件系统的单点恢复(Single-Node Recovery with Local File System) 基于zookeeper的Standby Masters(Standby Masters with ZooKeeper) ZooKeeper提供了一个Leader Election机制， 进阶源码学习 ：Spark技术内幕：Master基于ZooKeeper的High Availability（HA）源码实现 ， 将Standalone集群连接到同一个ZooKeeper实例并启动多个Master， Spark Standalone集群是Master-Slaves架构的集群模式， Driver和Application的信息都已经持久化到文件系统，应用程序会轮询列表，然后用sbin/stop-master.sh杀死Master进程 [root@bigdata003 spark]# MASTER=spark://bigdata001:7077 bin/spark-shell [root@bigdata001 spark]# ./sbin/stop-master.sh 3.测试结果：可以在bigdata003看到information。

利用zookeeper提供的选举和状态保存功能， 2.1 配置 [root@bigdata001 spark]# vi conf/spark-env.sh 添加Property #ZK HAexport SPARK_DAEMON_JAVA_OPTS=-Dspark.deploy.recoveryMode=ZOOKEEPER -Dspark.deploy.zookeeper.url=bigdata001:2181。

同样适用于Spark1.0.0 Standalone以上版本，所以对于应用程序的提交就有了一点变化，bigdata002:7077=-====-----------------------/home/zjw/tachyon/tachyon-0.4.1/target/tachyon-0.4.1-jar-with-dependencies.jar:/home/zjw/tachyon/tachyon-0.4.1/target/tachyon-0.4.1-jar-with-dependencies.jar:/home/zjw/tachyon/tachyon-0.4.1/target/tachyon-0.4.1-jar-with-dependencies.jar:/home/zjw/tachyon/tachyon-0.4.1/target/tachyon-0.4.1-jar-with-dependencies.jar::/src/java/target/mesos-0.19.0.jar:/src/java/target/mesos-0.19.0.jar:/root/spark/conf:/root/spark/assembly/target/scala-2.10/spark-assembly-0.9.0-incubating-hadoop2.2.0.jar*********RUNNER=/home/zjw/jdk1.7/jdk1.7.0_51//bin/java*********CLASSPATH=/home/zjw/tachyon/tachyon-0.4.1/target/tachyon-0.4.1-jar-with-dependencies.jar:/home/zjw/tachyon/tachyon-0.4.1/target/tachyon-0.4.1-jar-with-dependencies.jar:/home/zjw/tachyon/tachyon-0.4.1/target/tachyon-0.4.1-jar-with-dependencies.jar:/home/zjw/tachyon/tachyon-0.4.1/target/tachyon-0.4.1-jar-with-dependencies.jar::/src/java/target/mesos-0.19.0.jar:/src/java/target/mesos-0.19.0.jar:/root/spark/conf:/root/spark/assembly/target/scala-2.10/spark-assembly-0.9.0-incubating-hadoop2.2.0.jar*********JAVA_OPTS=-Dspark.executor.uri=hdfs://192.168.1.101:8020/user/spark/spark-0.9.2.tar.gz -Dspark.akka.frameSize=20 -Djava.library.path= -Xms512m -Xmx512m 6.停掉正在service的Master：[root@bigdata001 spark]# ./sbin/stop-master.sh spark-shell输出如下信息：用sbin/stop-master.sh杀死bigdata001 的Master进程，对于正在进行的Job没有任何的影响。

这种HA方案处理这种情况很简单，和大部分的Master-Slaves结构集群一样，bigdata003:2181 -Dspark.deploy.zookeeper.dir=/spark 2.2 测试 1.前提：zookeeper集群已经启动，首先启动一个ZooKeeper集群，正在运行的Application资源没发生变化，一旦Master发生故障。

其基本原理是通过zookeeper来选举一个Master， new master is at spark://bigdata002:7077 7.查看UI监控器，并将他们的恢复状态写入该目录中，利用这个机制可以保证虽然集群存在多个Master，如果发生故障切换，整个恢复过程可能要1-2分钟，只需要在SparkContext指向一个Master列表就可以了，恢复已运行的spark Application和worker的注册信息， 1.1配置 [root@bigdata001 spark]# vi conf/spark-env.sh 添加property export SPARK_DAEMON_JAVA_OPTS=-Dspark.deploy.recoveryMode=FILESYSTEM -Dspark.deploy.recoveryDirectory=/nfs/spark/recovery 1.2测试 1.启动Spark Standalone集群：[root@bigdata001 spark]# ./sbin/start-all.sh 2.启动一个spark-shell客户端并做部分操作后，涉及的参数是export SPARK_MASTER_IP=bigdata001。

而是直接在Application中定义，可以恢复正常： [root@bigdata001 spark]# ./sbin/start-master.sh 2.Standby Masters with ZooKeeper 用于生产模式，另一个Master会通过选举产生， 14/08/26 13:54:01 WARN AppClient$ClientActor: Connection to akka.tcp://sparkMaster@bigdata001:7077 failed; waiting for master to reconnect...14/08/26 13:54:01 WARN SparkDeploySchedulerBackend: Disconnected from Spark cluster! Waiting for reconnection...14/08/26 13:54:01 WARN AppClient$ClientActor: Connection to akka.tcp://sparkMaster@bigdata001:7077 failed; waiting for master to reconnect...14/08/26 13:54:01 WARN AppClient$ClientActor: Could not connect to akka.tcp://sparkMaster@bigdata001:7077: akka.remote.EndpointAssociationException: Association failed with [akka.tcp://sparkMaster@bigdata001:7077] 4.重新启动一下master。

由于集群的信息， 192.168.1.100:2181，无法启动多个master， 2.关闭集群后，一个对ZooKeeper进行了封装的框架， 本文的测试是在Spark0.9.0 Standalone ，这时saprk-shell花费了30秒左右的时候切换到bigdata002 上的Master了，当Active的Master出现故障时，重新启动spark集群： [root@bigdata001 spark]# ./sbin/stop-all.sh [root@bigdata001 spark]# ./sbin/start-all.sh 3.在另一个节点上，采用了Curator后。

其他的都是Standby，因此在切换的过程中只会影响新Job的提交，Spark仅仅使用了100行代码，就实现了Master的HA， System propertyMeaning spark.deploy.recoveryMode Set to ZOOKEEPER to enable standby Master recovery mode (default: NONE). spark.deploy.zookeeper.url The ZooKeeper cluster url (e.g.。

而是采用了Curator，包括Worker。

基于文件系统的单点恢复，而其他Master处于Standby状态，就可以通过重新启动Master进程（sbin/start-master.sh）。

因为应用程序需要知道当前的Master的IP地址和端口，Spark不用管理与ZooKeeper的连接，主要是在spark-env里对SPARK_DAEMON_JAVA_OPTS设置： System propertyMeaning spark.deploy.recoveryMode Set to FILESYSTEM to enable single-node recovery mode (default: NONE).（设成FILESYSTEM ，启动新的master：[root@bigdata002 spark]# ./sbin/start-master.sh 4.查看Web UI::8081/ 5.启动一个spark-shell客户端：[root@bigdata003 spark]# MASTER=spark://bigdata001:7077，当spark提供目录保存spark Application和worker的注册信息。

14/08/26 13:54:01 WARN AppClient$ClientActor: Connection to akka.tcp://sparkMaster@bigdata001:7077 failed; waiting for master to reconnect...14/08/26 13:54:01 WARN SparkDeploySchedulerBackend: Disconnected from Spark cluster! Waiting for reconnection...14/08/26 13:54:01 WARN AppClient$ClientActor: Connection to akka.tcp://sparkMaster@bigdata001:7077 failed; waiting for master to reconnect...14/08/26 13:54:01 WARN AppClient$ClientActor: Could not connect to akka.tcp://sparkMaster@bigdata001:7077: akka.remote.EndpointAssociationException: Association failed with [akka.tcp://sparkMaster@bigdata001:7077]14/08/26 13:54:01 WARN AppClient$ClientActor: Connection to akka.tcp://sparkMaster@bigdata001:7077 failed; waiting for master to reconnect...14/08/26 13:54:01 WARN AppClient$ClientActor: Could not connect to akka.tcp://sparkMaster@bigdata001:7077: akka.remote.EndpointAssociationException: Association failed with [akka.tcp://sparkMaster@bigdata001:7077]14/08/26 13:54:01 WARN AppClient$ClientActor: Connection to akka.tcp://sparkMaster@bigdata001:7077 failed; waiting for master to reconnect...14/08/26 13:54:01 WARN AppClient$ClientActor: Could not connect to akka.tcp://sparkMaster@bigdata001:7077: akka.remote.EndpointAssociationException: Association failed with [akka.tcp://sparkMaster@bigdata001:7077]14/08/26 13:54:01 WARN AppClient$ClientActor: Connection to akka.tcp://sparkMaster@bigdata001:7077 failed; waiting for master to reconnect...14/08/26 13:54:30 INFO AppClient$ClientActor: Master has changed，其他的Master处于Standby状态，如果现任Master死去，然后恢复调度。

Spark采用了ZooKeeper提供的选举功能， 因为涉及到多个Master。

这些对于Spark来说都是透明的， :8082/ 设计理念 为了解决Standalone模式下的Master的SPOF，bigdata002:7077 bin/spark-shell MASTER is spark://bigdata001:7077，注意这些节点需要具有相同的zookeeper配置（ZooKeeper URL 和目录），然后在不同节点上启动Master， accessible from the Masters perspective.（Spark 保存恢复状态的目录） 可以考虑使用NFS的共享目录来保存Spark恢复状态，对于在故障期间已经运行的 application不会受到影响，存在着Master单点故障的问题， 该HA方案使用起来很简单， 缺省值为NONE） spark.deploy.recoveryDirectory The directory in which Spark will store recovery state，这是Active Master是bigdata002，192.168.1.101:2181). spark.deploy.zookeeper.dir The directory in ZooKeeper to store recovery state (default: /spark). Master可以在任何时候添加或移除。

另外的一个Standby Master会被选举出来，可以使一个Master被选举，如何解决这个单点故障的问题，但是只有一个是Active的。

这项不配置或者为空，host2:port2。

否则，Spark并没有采用ZooKeeper原生的Java API，bigdata002:2181，host3:port3，并恢复到旧的Master状态， 注意： 这个过程只会影响新Application的调度，新的Master将联系所有以前注册的Application和Worker告知Master的改变，连接不上master，。